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A HTR RARCHY MODEL 

Background of the Invention 

The present invention relates to a hierarchy model for modelling the security policy of a business, 
5 and in particular, to a hierarchy model which when implemented is capable of allowing security 
administrators to centrally manage user and application security related attributes (authentication methods, 
access rights, privileges, access control rules) and o&er application attributes. 

Description of the Prior Art 

10 The reference to any prior art in this specification is not, and should not be taken as, an 

acknowledgment or any form of suggestion that the prior art forms any part of the common general 
knowledge in Australia 

Security administration in a large-size, mission-critical and security-sensitive enviit>nment is a big 
challenge when many different applications (web servers, application severs, etc), and thousands of 
1 S different users (employees, partners, customers) need be managed 

In particular, it is necessary to consider 

1) How to define and enforce an enterpiise-wide security policy in a large organization? 

ft 

2) How to support separation of duties to prevent giving too much power to one person or functional role? 

3) How to manage thousands of different users (eii^>loyees, partners, customers), their credentials and 
20 privileges? and, 

4) How to manage diffi^nt web-enabled mission-critical and security-sensitive apphcations? 

There are very few research papers in the security administration area, although a number of 
attempts have been made by the industry to implement simple security administration models. These 
25 include using techniques such as: 

1) Having individual departments manage their own business applications; 

2) Using distributed security system with separate security domains for different departments or/and 
business applications; 

3) Providing centralized security administration; and, 
30 4) Delegating some or all the security administration. 

However, these solutions suffer fi-om a number of drawbacks. 

In the first case, if individual departments are allowed to manage their security poUcies, then it is 
impossible to define and enforce enterprise wide security policies due to the logistics of the problem. This 
35 can have significant drawbacks if different departments end up with significantiy different policies that are 
effectively incompatible, as this can lead to the security of one or more departments being con^romised. 

In the second exanq)le, reasonable security can be achieved for separate or less-connected 
businesses. However, cross-domain communications, particularly across different web applications, will 
remain a problem. In addition to this, it is again difficult to define and enforce enteiprise wide security 
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policies. 

In the third case, it is practically imfeasible to manage a large nmaber of users and multiple 
applications in a distributed, heterogeneous con^}uting environment In addition to fliis, security 
administrators are required to know multiple inconsistent administration interfaces that eventually become 
5 bottlenecks to the implementation of a business wide policy. 

Finally in the fourth case, granular administration rights are not defined. Furthermore, effective 
delegation scopes are not clear and accordingly, delegation without granularity "wiU not allow for effective 
overall control 

Accordingly, enterprise-wide security policy cannot be easily and effectively enforced by current 
10 security systems. As a result, organizations resort to manual procedures for segregation of duties and 
security privilege enforcement, thus reducing the effectiveness of any security policy. 

In addition to this, current systems are unable to securely track the day t:o day activities of users of 
the security policy. Accordingly, when a security problem arises, it can be difBaidt to determine ^ere and 
when the breach of policy occurs. 
15 As a result, there is need for a security administration solution to manage access control or 

authorisation decisions and security policies in multiple-tier, mission-critical application environments. 

Summary of the Present Invention 

In a first broad form, the present invention provides a hierarchy model for nxodeling the security policy 
20 of a business, the hierarchy model including: 

a) A number of segment nodes, each segment node being used to define the security policy which 
applies to a respective segment of the business, each segment being associated with a number of 
respective individuals and/or applications, each segment node incliading at least one of the 
following: 

25 i) A prinpipal node, the principal nodes being used to define die security policy which applies to 

respective individuals within the busiaess, each principal node incluiding one or more principal 
entities, and each principal ratity corresponding to a respective indi^vidual; 
ii) An appUcation node, the application nodes being used to define the security policy which 
applies to respective appUcations or objects within the business, each appUcation node 
30 including one or more application or object entities, and each a.ppUcation or object entity 

corresponding to a respective application or object; 
in) A groiq> node, the group nodes being used to define the security policy which applies to 
respective groups of principals within the business, each group node including one or more 
group entities, and each groiq) entity corresponding to a group of respective individuals; 
35 b) A number of connections, the connections defining associations between the nodes to reflect the 

structure of the business. 

In a second broad form, the present invention provides a method of genera.ting a hierarchy model for 
modeling the security policy of a business, the mefliod including: 
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a) Defining the business as a number of segments, each segment being a respective unit within the 
business; 

b) Determining the individuals, groups of individuals and/or applications associated with each unit; 

c) Defining a number of segment nodes, each segment node being used t:o define the security policy 
5 which appUes to a respective segment of the business; 

d) Defining at least one principal, group and/or application node, ea.ch principal, group and/or 
application node being used to define the security policy which applies to respective individuals, 
groups of individuals and/or applications; and, 

e) Defining a number of connections between the defined nodes in accordance with the relationships 

■ 

10 between the segments, individuals and/or apphcations to reflect the staicture of the business. 

In a third broad form, the present invention provides a compute program product including 
computer executable program code for generating a hierarchy model in accordance with the method of the 
first broad form of the invention. 

In a fourth broad form the present invention provides a system for generating a hierarchy model for 
IS modeling the security policy of a business, the hierarchy model including: 

a) An ii^t, adapted to receive inputs: 

i) Defining the business as a number of segments, each segment being a respective unit within 
the business; 

ii) Identifying the individuals and/or applications associated with each unit; 

20 iii) Defining a nuntiber of segment nodes, each segment node being used to define the security 

policy which applies to a respective segment of the business; 
iv) Defining at least one principal, group and/or application node, each principal, groiq> and/or 

application node being used to define the security policy vs/hich applies to respective 

individuals, groups of individuals and/or applications; and, 
25 v) Defining a number of connections between the defined nodes in accordance with the 

relationships between the segments, individuals and/or applicatioiis to reflect the structure of 

the business. 

b) A store; and, 

c) A processor ad^ted to: 

30 i) Generate a number of tables in the store; 

ii) Associate each table with a respective node in the hierarchy model; and, 

iii) Define a mmiber of links between the tables, each link representing a connection between 
respective nodes within the tables. 

Accordingly, the present invention provides a hierarchy model for modelling security pohcy of a 
35 business, as well as a method, a conqjuter program product and a system for generating such a model. 

The model includes a number of segment nodes, which can in turn iaclude a number of principal, 
appUcation or group nodes. The business is modeled in terms of a number of interconnected segment 
nodes, with the principal, group, and application nodes being used to represent individuals, groups of 
individuals, and applications/objects within the business respectively. This in turn allows tiie security 
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policy to be defined for the segments of the business separately or in conjunction with othex segments, 
allowing a security policy to be defined for smaller units of a business separately. 

This technique can be extended so that the segment include related external organisations, such as 
external suppliers, thereby allowing die hierarchy model to be used in modelling the security policy of a 
5 business on its own, or of a business and its related external organisations. 

Using this technique the defined poUcy can apply to the business as a whole, or to dif!ferent units, 
such as departments within the business, as well as related external organisations. Respective security 
administrators can then be used to define variations in the overall policy to each segment. Policies applied 
to a given segment are tiien applied to the associated individuals, groups or applications prinoipal so that 
10 the security policy applies to all entities within the entire business. 

The respective individual may conespond to a functional (non-interactive) identity^ within the 
business. Typicsdly, within a multi tier environment there are one or more servers, daemons or the like, 
which need to login to the security system in order to perform actions, or complete tasks, on belnalf of users 
of the system (individuals). Accordingly, in order to be able to login to the security system, tiie severs, 
IS daemons or the like, need respective identities. As the servers or the like are imable to handle interactive 
login prompts, these identities are refmed to as non-interactive ids. Accordingly, the indi'viduals may 
comprise a server, daemon or the like. 

Thus it will be appreciated that the hierarchy model can be used for modelling security 
administration, as well as security policy: 
20 Typically each segment node may include one or more child segment nodes, each cl:uld segment 

node defining the security policy for a logical unit within the respective parent segment Thus, for 
exanq)le, a parent segment could be a regional ofiice with the child segment forming a department within 
the office. 

The hierarchy model usually fiuiher includes at least one root segment node, the root segment node 
25 being a segment node with no parent nodes. This can be used to represent the security policy for the 
overall business, with variations firom this policy being defined in the child segments as required. Thus, 
this allows common security policies which would be applied to all segments to be factored out into a 
single root segment node. 

The model typically further includes application collection entities, each appUcation collection 
30 entity representing a coUection of apphcation entities. Again, this allows common security policies which 
would be applied to a number of applications to be factored out into application collections.. 

Usually the model is in^lemented within a database, the database including a number of tables, 
each table representing a respective type of node within the model. This can allow the database structure to 
reflect the structure of the hierarchy model allowing changes to the hierarchy model to be easily 
35 implemented within the database. Furthermore, transfer of security policy fix)m one level of the hierarchy 
model to another can easily be implemented by propagating data between the tables in the datiabase. This 
allows the present invention to be implemented using a relational database, or the like. 

Accordingly, the database usually includes a segment table, with each segment node being 
represented by a respective entry within the segment table. 
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Similaily a principal table is usually provided with each principal ^tity being represented by a 
respective entry within the principal table» a groiq) table, mth each group entity being represented by a 
respective entry within the group table and an applications table, with each application entity, object entity 
and application collection entity being represented by a respective entry in the application table. 
S Furthermore, the number of comiections are preferably represented by links between entries in the 

tables. 

Preferably each node within the model has an associated number of security settings, the security 
policy being defined by selecting appropriate ones of the security settings. In tiiis case, each type of node 
can have respective security settings. Typically, a number of standard security settings will be pre-defined 
10 associated with each model. However, it will also typically be possible to add in additional security 
settings should this be necessary. 

Typically the security settings or other application attributes available including settings relating to 
password length, Gxpky duration, minimum age, and the like, . although restrictions on access to 
^plications and information can al.so be defined 
15 Typically each entry is defined in a respective row of the respective table, with eacki security 

setting being defined within a respective column. 

Typically each node is defined in a respective row of the respective table, the security settdng being 
defined in a respective column. Thxis, the database will typically contain a segment table that: includes 
details of each segment in a respective row of the table. The security settings for each segment can tiien be 
20 defioied within respective columns such that the security settings for all the nodes at a given level xvitfain the 
hierarchy are defined in a single table. However, any database structure, could be used 

In a fifth broad form, the present invention provides a method of defining a security policy for a 
business, the method including: 

a) Defining the business in terms of a hierarchy model, the hierarchy model including: 

25 i) A number of segment nodes, each segment node being used to define the security policy which 

applies to a respective segm^t of the business; 
iO At least one principal, group and/or application node, eadi principal, group and/or application 

node being used to define the security policy which applies to respective individuals, groups of 

individuals and/or applications; and, 
30 iii) A number of connections between the defined nodes, the comiections representing the 

relationships between the segments, individuals and/or applications to reflect the .structure of 

the business. 

b) Specifying the security policy for at least some of the nodes in the hierarchy model; and, 

c) Propagating the specified security poUcy to other nodes in the hierarchy model. 

35 In a sixth broad form, the present invention provides A computer program product including computer 
executable code for defining a security policy for a business in accordance with the method oi' the fifth 
broad form of the invention. 

In a seventh broad form, the present invention provides a system for defining a security policy for a 
business or extend organisations, die system including: 
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a) A system for defining tbe business in terms of a hierarchy model, the hierarchy model including: 

i) A number of segment nodes, each segment node being used to define the security policy which 
' applies to a respective segment of the business or extended organisations; 

ii) At least one principal, group and/or application node, eadi principal, group and/or application 
S node being used to define the security policy which applies to respective individuals, groups of 

individuals and/or applications; and, 

iii) A number of connections between the defined nodes, the connections representing tiae 
relationships between the segments, individuals and/or applications to reflect the structure of 
the business. 

10 b) An input, adapted to receive inputs specifying the security policy for at least one of the nodes in 

the hierarchy model; and, 

c) A store for storing the specified security policy; and, ' 

d) A processor adapted to propagate the specified security policy to other nodes in the hierarcbiy 
model. 

15 Accordingly, the present invention also provides a method, a conq)uter program product and a systexn 
for defining a security policy for a business. This can also be extended for use with ext^ded organisatioixs. 

' This generally uses the hierarchy model of the first broad form of the present invention. AccordingL3r, 
the technique of the invention involves defining the businesses in terms of the hierarchy model, specifying 
the security policy for some nodes and, propagating the specified security policy to other nodes. 

20 Typically the method of specifying the security policy for a node includes: 

a) Generating security data defining security settings for the respective node; and, 

b) Inputting the security data as part of the respective entry within the respective table within ttie 
database. 

The method usually fiirther involves propagating the defined security settings to other nodes in ttie 
25 hierarchy model by propagating the security data to other linked entries in the database. Thus, this provides 
a technique for having the database automatically updated by a propagating security data throughout ttie 
database. This propagation is carried out in such a way that the security policy can be defined for segments 
and ihen propa^ted to child segments automatically. However, the security settings q}pUed to a chOd 
segment node may override the security settings propagated firom the respective parent segment node. 3n 
30 this circiunstance, the method can be controlled to prevent the security poUcy appUed to a child segmexit 
firom being weaker than the security policy of the parent segment 

In a eighth broad form, the present invention provides a mediod of implementing a security policy for a 
business, the method including: 

a) Defining a security poUcy for the business, the security policy being defmed in terms of a 
35 hierarchy model including: 

i) A number of segment nodes, each segment node representing a respective segment of ttie 
business; 
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ii) At least one principal, group and/or application node, each, principal, group and/or application 
node representing a respective individual, group of individuals and/or applications within the 
business; and, 

iii) A number of connections, the connections defining the associations between the nodes, the 
5 security policy being defined by security settings associated with each node; 

b) Monitoring action to be taken by a respective segment, iadividual or application within the 
business; 

c) Determining if ffae action is permissible in accordance with the defined security settings; and, 

d) Allowing or preventing the action in accordance with the result of the determination. 

10 Jna, ninth broad form, the present invention provides a conq^uter program product including computer 

executable code for implementing a security poUcy in accordance with the method of the eighth broad form 
ofthe present invention. 

In a tenfli broad form, the present invention provides a system for ixnplementing a security policy for a 
business, the system including: 
IS a) A system for defining a security policy for the business, the security policy being defined in terms 

of a hierarchy model including: 

i) A number of segment nodes, each segment node representing a respective segment of the 
• business; 

ii) At least one principal, group and/or application node, each, principal, group and/or application 
20 node representing a respective individual, group of individuals and/or explications within the 

business; and, 

iii) A number of connections, the connections defining the a,ssociations between the nodes, the 
security pohcy being defined by security settings associated with each node; and, 

b) A processor, the processor being adapted to: 
25 i) Monitor action to be taken by a respective segment, individual or application within the 

business; 

ii) Determine if the action is permissible in accordance with the defined security settings; and, 

iii) Allow or prevent the action in accordance with the result of the determination. 
Accordingly, the present invention also provides a method, a computer program product and a system 

30 for implementing a security policy. This is achieved by monitoring actions to be taken by respective 
segments, individuals or applications within the business and then deteTmining if this action is permissible 
in accordance with security settings defined within the hierarchy model. This then allows the action to be 
prevented or allowed depending on the security settings defined. 

Typically the security settings are stored in a database associated with the respective segment, 

35 principal, group and/or object node, the method of determining if the action is permissible including: 

a) Accessing the database to determine the security settings for the respective segment, individual 
and/or application; and, 

b) Comparing tiie accessed security settings to the action to be taken to determine if the action is 
permitted. 
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Preferably, the hierarchy model is a model according to the first broad form of the present invention. 
In an eleven^ broad form the present invention provides a method of controUing the security policy of 
a business, the security policy being defined using a hierarchy model including: 

a) A number of segment nodes, each segment node having an associated number of security settings, 
the segment node being used to define the security policy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 

b) A number of connections, the connections defining associations between the segment nodes to 
reflect the structure of the business, the method including: 

i) Assigning an administrator to each segment; , 

ii) Defining administration rights that can be assigned to any administrator, the administration 
rights controlling the administration procedures the respective administrator can perform; and, 

iii) Assigning appropriate ones of the administration rights to the administrator, if required. 

In a twelfth broad form the present invention provides a computer program product for controlling the 
administration of the security policy of a business, the computer program product including con:iputer 
executable code for performing the method of the elevrath broad form of the present invention. 

In an thirteenth broad form the present invention provides a system for controlling the administration 
of the security pohcy of a business, the security policy being defined using a hierarchy model including: 

a) A number of segment nodes, each segment node having an associated number of security settings, 
the segment node being used to define the security policy vAich applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 

b) A number of connections, the connections defining associations between the segment nodes to 
reflect the structure of the business, the system including: 

i) An input for: 

(1) Receiving an indication of an adnoinistrator assigned to each segment; , 

(2) Defining administration rights that can be assigned to any administrator; and, 

(3) Assigning appropriate ones of the administration rights to the administrator, if required; 
and, 

ii) A processor adapted to control the administration procedures the respective administrator can 
perform in accordance with the assigned administration rights. 

Accordingly the present invention seeks to provide a method, computer program and system for 
controlling the administration of the security policy of a business. This is achieved by having 
administrators assigned to respective segments, and then controlling the action that can be taken by the 
administrators. This is achieved by the use of granular administration rights which control the 
administration actions an administrator can perform, including the rights to alter security policy and 
settings, as well as the rights to read/view various policy settings. 

Typically the method of assigning the administrator includes defining an administrator entity for each 
segment, the administrator entity representing a respective individual within the business. 

In this case, the method of controlling the administration rights usually includes assigning appropriate 
ones of the administration rights to the defined administrator entity. 
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Preferably the administration rights are defined at the system level. 

In a fourteenth broad fonn the present invention provides a method of controlling the administration of 
the security poUcy of a business, the security policy being defined using security settings, the method 
involving: 

5 a) Assigning first and second administrators to control alteration of the security settings; 

b) Controlling the first administrator to only allow the first administrator to propose <dianges to the 
security settings; and, 

c) Controlling the second administrator to only allow the second administrator to accept or reject 
proposed changes to the security settings, thereby allowing the first and second administrators to 

1 0 control the security settings. 

In a fifteenth broad form the present invention provides a computer program product including 
conq>uter executable code for controlling the administration, of ^ security poUcy of a business in 
accordance with the method of the fourteenth broad form of the present invention. 

In a sixteenth broad form the present invention provides a system for controlling the administration of 
15 the security policy of a business, the security poUcy being defined using security settings, the system 
including: 

a) An input for assigning first and second administrators to control alteration of the security settings; 
and 

b) A processor adapted to: 

20 i) Control the first administrator to only allow the first administrator to propose changes to the 

security settings; and, 

ii) Control the second administrator to only allow the second administrator to accept or reject 
proposed changes to the security settings, thereby allowing the first and second administrators 
to control the security settings. 
25 Typically the method of assigning the first and second administrators includes defining first and 

second administrator entities, the first and second administrator entities representing respective individuals 
within the business. 

The method of controlling the administrators usually involves: 

i) Defining a number of administration rights that can be assigned to any adnoinistrator entity, the 
30 administration rights controlling the administration procedures the respective administrator 

can perform; ; and, 

ii) Assigning appropriate ones of the administration rights to the respective administrator entity. 
The administration rights are usually selected ones of the seciuity settings and wherein the 

administration rights are selected to prevent an administrator altering the administration rights of their own 
35 respective administrator entity. 

Typically the hierarchy model is a model according to the first broad form of the present invention. 
In a seventeentii broad form the present invention provides a method of controlling the administration 
of the security policy of a business, the security policy being defined using a hierarchy model including: 
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a) A niunber of segment nodes, each segment node havinjg an associated number of security settings, 
the segment node being used to define the security policy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 

b) A number of coimections, the connections defining associations between the segment nodes to 
S reflect the structure of the business, the method including: 

i) Assigning an administrator to each segment, the administrator being responsible for the 
security settings of the respective segment; and, 

ii) Allowing a Gist administrator to delegate responsibility for the security settings of a respective 
segment to a second administrator. 

10 In an eighteenth broad form the present invention provides a computer program product including 
conq)uter executable code for controlling the administration of the security policy of a business in 
accordance with the method of the seventeenth broad form of the present invention. 

Jn a nineteenth form the present invention provides a system for controlling the administration of the 
security policy of a business, the security policy being defined using a hierarchy model including: 
IS a) A number of segment nodes, each segment node having an associated number of security settings, 

the segment node being used to define the security policy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 
b) A number of connections, the connections defining associations between the segment nodes to 
reflect the structure ofthe business, the system including: ^ 
20 i) An input for assigning an administrator to each segment, the administrator being res^nsible 

for the security settings of the respective segment; and, 
ii) A processor adapted to allow a first administrator to delegate responsibility for the security 
settings of a respective segment to a second administmtor. 
Typically the method of delegating responsibility includes: 
' 25 a) Determining if the administration rights for the first administrator allow responsibility to be 

delegated to the second administrator; and, 
b) Selecting some or all of the administration rights for the second administrator to correspond to the 
administration right for the first administrator, thereby allowing the second administrator to 
perform some or all fimction of the first 
30 In a twentieth broad form the present invention provides a method of monitoring a security system 
inq)lementing a security server, the method including: 

a) Causing the security server to generate an indication of each action taken on the security systen^ 

b) Digitally signing the indication of each action; and, 

c) Storing the digitally signed indication. 

35 In a twenty first broad form the present invention provides a computer program product including 
computer executable code for monitoring a security system in accordance with the method ofthe twentieth 
broad form of the present invention. 

In a twenty second broad form the present invention provides a system for monitoring a security 
system implementing a security server, the system con^rising: 
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a) An input for receiving an indication of each action taken on the security system; 

b) A processor for digitally signing the indication; and, 

c) A store for storing the digitally signed indication. 

Accordingly, the present invention provides a method, computer program and a system for monitoring 
5 a security system. This is achieved by storing an indication, such as an audit log, recording actions that 
have be taken by the security system, thereby allowing the actions taken to be determined at a later date. 
The method usually includes storing the digitally signed indication in a table, each digitally signed 
indication being stored in a respective portion of flie table. 

Typically the security server is adapted to generate an authorisation or rejection indication in response 
10 to a request to perform an action, and wherein the method further includes causing the security server to 
generate an indication of each authorisation or rejectioa 

Digital signature ensures the integrity of the stored ihformatioiL Preferably the store is located remotely 
to the security system on a dedicated system, such as one or more dedicated servers. This ensures the 
security of &e stored infoimation. 
15 Accordingly, the security system based on above model offers a &cility to centralize authentication, 
autkorization and administration functions. The security system allows security administrators to centrally 
manage user and appUcation security-related attributes, authentication methods (such as passwords, 
dynamic passwords or X.509 certificates), rights, privileges and access controls rules. This is achieved by 
using a central security systrai whenever applications need to access a resource on behalf of a user. The 
20 security server responds to the users or £^plications by referring to the policies and access control rules in 
its authorization database. 

Brief Descriotion of the Drawings 

An example of the present invention will now be described with ref^ence to the accompanying 
25 drawings, in which:- 

Figure 1 is a schematic diagram of a network root segment including a security server according to 
the present invention; 

Figure 2 is a schematic diagram showing the fiinctionahty of the security system of Figure 1; 
Figure 3 is a schematic diagram pf one of the security servers shown in Figure 2 
30 Figure 4 is a schematic diagram of a hierarchy model according to the present invention; 

Figure 5 is a screen shot taken &om the graphical user inter&ce (GUI) of the policy server of 
Figure 3, when defining die security policy of a segment node; 

Figure 6 is a screen shot taken fiom the graphical user interface (GUI) of the policy server of 
Figure 3, when defining the privileges of a principal; and, 
35 Figure 7 is a screen shot taken from the graphical user interface (GUl^ of the policy server of 

Figure 3, when defining the access rights to an application. 

Detailed Description of the Preferred Embodiments 

An example of a system suitable for inq>lementing the present invention is shown in Figure 1. As 
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shown the system includes a communications network 1 which fomis the internal netwoik of a business. 
Accordingly, the communications network 1 could range from a small Ethernet LAN (local area netwoik), 
to a global WAN (wide area network) which is fonned &om a number of networks distributed throughout 
the world. 

S Coupled to the network 1 is a number of user end stations 2, which allow users to access the 

network and any of the services or information contained thereon. The end stations 2 may be any form of 
suitable processing system, and may be connected to the network 1 using ei&er wired or wireless 
connections, as will be appreciated by pmons skilled in the art 

In order to provide the log on security, a security system 3 is provided, as will be described in 
10 more detail below. 

Also coupled to the netwoik 1 is a web server 4 which is used to provide facilities such as a web 
site on the Internet 5, which is coupled to the network 1, as shown. In general, access to the Internet 5 is 
controlled using an appropriate firewall. 

In addition to the user end stations 2 coupled to the netwoik 1, access to the netwoik can also be 
IS achieved in a nimiber of different ways. Thus for example, the network 1 could be accessed using end 
stations 8 which are coupled to the Internet 5, via the Internet 5 and the web server 4. Alternatively, access 
could be achieved &om mobile communications systems 9, such as a WAP or GPRS enabled mobile 
phone, or a lap top computer with a modem. In diis case, access coiild be achieved by dialing into the 
netwoik directly, or by establishing a connection via the Internet 5. hi either of these cases, &is will allow 
20 remote users, such as clients of the business, or employees located out of the office, to access the network 
1. 

The remainder of the description wiU be limited to describing the example of tiie end stations 2, 
although it will be appreciated that access using the end stations 8, or the mobile communications system 9 
will be in a similar manner. 

25 An application server 6 is provided to allow useis of the end station 2 to access various 

q>plications, and a database server 7 is provided to allow the users of the end station 2 to access databases 
connected to the network 1. 

The fimctionality of the security system 3 is shown in more detail in Figure 3. As shown, the 
security server includes a policy server 20, which is used to define a security pohcy for the business. An 

30 access server 23 is provided for implementing the defined security policy, whilst a service server 26 is used 
to configure and monitor the status of the other servers 20, 23. 

The configuration of each of the servers 20, 23, 26 is shown in more detail in Figure 2. As shown, 
the servers typically include a network interface card 10 for coupling the server to the netwoik 1. The 
network interface card 10 is in turn coupled to a processor 12 and a memory 13 via a bus 11. An 

35 input/output device (I/O device) 14 is also typically provided, usually in the fonn of a keyboard and 
monitor to allow information to be entered and obtained fi'om the security server 3. 

Accordingly, it will be appreciated that each of the servers 20, 23, 26 may be any form of 
processing system, such as a peisonal computer, or the like, ^ch is configured in accordance' with the 
present invention. This is typically achieved by having the processor 12 execute applications software 
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generated in accordance wiQi the present invention which results in &e functionality of flie servers 20, 23, 
26 being as shown in Figure 2. In this exanople, whilst three separate servers 20, 23, 26 are shown, it will 
be realized that the invention may be implemented on a single server, or on a larger number of servers 
distributed globally, depending on the circumstances. 
5 Thus, as shown, the policy server 20 includes a policy daemon 21 and a report daemon 22, the 

access server 23 includes an auAentication daemon 24, an authorization daemon 25, and an audit daemon 
29. The service server 26 implements a configure/monitor 27 which operates to monitor and configure the 
other servers 20, 23, as required. 

The daemons 21, 22, 24, 25, 29 are implemented within the processors 12 of the respective servers 
10 20, 23, 26. In addition to this, each server 20, 23, 26 implements an API layer 30, which is a library of 
code for implementing a number of APIs. The API library code will form part of the applications software 
executed by the processors 12 of each of the servers 20, 23, 26, such that each of the servers 20, 23, 26 has 
access to a respective API layer 30, although for sinqjlicity only a single API layer is shown in Figure 2. 

In this example, the API layer includes a crypto-API 3 1 that is coupled to a key database 32 and a 
15 crypto Ubrary 33. The key database 32 and the crypto Ubrary 33 store the keys and rules which allow the 
each of the servers 20, 23, 26 to implement specific forms of cryptography. 

A registry API 34 is provided to couple the servers 20, 23, 26 to a user database 35, and a policy 
database 36 as shown. The user database 35 is used to store information regarding each of the potential 
users of the system, such as user names (or IDs) and passwords, as will be explained in more detail below. 
20 Similarly, the policy database 36 is used to store the security policy of the business which the servers 20, 
23, 26 define and then implement 

A log API 37 is provided to couple the servers 20, 23, 26 to a log store 38, the log store being used 
to maintain logs recording user access to the system, and a config API is provided to couple the 
configure/monitor 27 to a store of config files 40 which are used to configure the security server 3 for the 
25 particular operating envirormient 

Accordingly, the API layer is used as an interface between the servers 20, 23, 26 and the key 
database 32, the crypto library 33, the user database 35, the policy database 36, the log store 38, and the 
config file store 40 

Operation of the security system 3 according to the present invention will now be described. 
30 In general, as outlined above, the security system 3 operates to enforce a security policy which is 

defined for an entire business. 

In order to implement such a security poUcy, the security system 3 uses the access server 23 to be 
able to determine for each possible user of the end stations 2 the various access rights the respective user 
has. Thus, for example, certain users may only be provided with rights to access certain enterprise 
35 resources provided by the network system. Thus for example, use of the applications contained on the 
applications server 6, or use of some of the information available on the database server 7, may be limited 
for some users. 

Accordingly, it is necessary for the access server 23 to be able to identify each user individually, as 
well as to be able to determine the access privileges that each user has. 
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The exact manner in which a user is identified may vary. Accordingly, the user may be asked to 
provide a user name and associated secret password, a user certificate, a dynamical password, or other 
suitable form of user ideatifier. 

In general, the identification process is performed when the user attempts to access, for exan[q>le, 
5 the web server 4 or the applications server 6. At this time, a Web Security Agent (WSA) contained in the 
web server 4, or an Application Security Agent (ASA) contained in the applications server 6, will pronq>t 
the user to enter flieir user identifier. The user identifier is entered by the user at the end station 2 before it 
is transferred to the WSA or ASA via the network 1 . 

Upon receipt of the user identifier, the WSA or ASA will forward the user identifier to die access 
1 0 server 23, which will operate to validate the request 

The access server 23 of the security server will then access the user database 35 to detennine if the 

* 

entered user identifier is valid. Thus, for example, if the user identifier is a user name and associated secret 
password, the access server will check that the entered password corresponds to &e entered user name, 
allowing die identity of the user to be confirmed. 
IS Once the identity of the user has been confirmed, the user is logged on to the system. At this stage, 

the access server 23 will assign a random session ID to the log in session of the user. Once this has 
occurred, the access server 23 will use the session ID to determine the current log in status of the user, as 
well as to determine the access privileges which are defined for the user in the security poUcy stored in the 
policy database. 

20 Once this has been achieved, each time an action is to be taken, the WSA or ASA will query fiie 

access server 23, which will in turn access the authorization daemon to determine if the action is allowable 
within the scope of the users access privileges. An indication of this will be transferred to the WSA or the 
ASA, thereby allowing the WSA and the ASA to control the user's access to applications or information 
stored in the servers 4, 6, 7. 

25 It will be appreciated fix>m this that it is therefore necessary to define for each user of the end 

stations 2 the respective access privileges. This can be achieved by using the policy server 20 of the 
present invention to define a global security policy for the entire business organization. 

In order to achieve this, the poUcy server 20 of the present invention allows a system 
administrator, or the like, to define a policy for the entire business organization by considering the business 
30 as a hierarchy structure formed firom a number of different nodes. 

The hierarchy structure generally includes segment nodes, principal nodes, group nodes, and 
applications nodes. The segment nodes are used by the policy officer to define security policies for 
different segments within the business. In general, a segment is taken to be a logical unit within the 
business, which is responsible for, or at least capable of, organising and administrating respective users, 
35 groups or applications. 

Each segment node may contain zero or one principal nodes, zero or one group nodes, zero or one 
application nodes, and zero or more segment nodes. 

If a first segment node contains a second segment node, the second segment node is sometimes 
referred to as a sub-segment, in that it relates to a smaller logical unit within the first segment. In this case. 
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the first segment and the second segment aie related to each other via a parent child relationship, witii the 
first segment node being the parent and the second segment node being the child. 

The principal node is used to define access privileges for one or more individuals within the 
respective segment of the business. In the case, the individuals ace referred to as principal entities and each 
5 principal node may contain zero or more principal entities. 

The group nodes are provided to set access privileges for groups of individuals. In general, each 
group node may or contain zero or more group entities,, with each group entity corresponding to a 

■ 

respective group of individuals. 

The application node is used to define access permissions for application entities and may contain 

10 zero or more application entities or application collection entities. Each application collection entity may 
contain one or more appUcation entities, whilst each application entity may contain one or more object 
entities. In this regard, the object entities may be any form of data object within the network system, and 
accordingly, the application entities (which are typically formed fix>m one or more object entities) may 
correspond to software applications utilised by the system shown in Fig. 1. 

IS In use, the poUcy officer therefore defines die security policy for a business by defining security 

poUcies at different levels within die hierarchy structure. 

Accordingly, in order to define a security policy for the business under consideration, the policy 
ofBcer must first define the business in terms of a hierarchy structure which includes a number of segment, 
principal, groiq) and application nodes. 

20 An example of such a structure is shown in Fig. 4. 

As shown the hierarchy structure includes a number of segment nodes, 60, 61, 62, 63, 64, 65, 66, 
67, 68. In this exanq)le, the segment node 60 has four child segment nodes (or sub-segments) 61, 62, 63, 
64 which are connected to the segment node 60 via respective relationships 61a, 62a, 63a, 64a. In this 
example, the segment node 60 does not include a parent segment node and accordingly, the segment node 

25 60 is referred to as a root segment node of the business, which represents the highest level at which security 
policy can be defined for this area of the business. 

As shown, the child segment 61 is in itself a parent segment of the segment node 65, which is 
connected to the segment node 61 via the relationship 65a. Similarly, the segment node 64 is also the 
parent segment for the segment nodes 66, 67, 68, as shown by the relationship 66a, 67a, 68a. 

30 As mentioned above, each segment can include zero or one principal nodes which allow the access 

privileges of individuals to be set. In this example, the segments 62, 65 are each shown as having a 
respective principle node 71, 72. Typically other segments will include a respective principle node, 
although this has not been shown for clarity purposes. 

The individuals, whose access privileges are defined by the principal nodes, are shown for 

35 example, at PI, P2, P3, P4. Thus, as shown it is possible for each principal node to specify the access 
privileges for a number of principal entities. 

A number of group nodes 73, 74, 75 are also shown. Again, each segment will only have zero or 
one group nodes. The group nodes are used to set access privileges for one or more group entities Gl, 02, 
G3, 04 which in turn specify the access privileges of one or more principal entities. Thus, a principal 



yfO 2002/067173 PCT/SG2002/000027 

-16- 

entity PI may join one or more groiq) entities Gl, G2, G4 as appropriate. 

Thus, for exanq)le, if the principal entity "Bob" represents an individual who is both an employGe 
of the company and a manager, then the "Bob" principal entity may belong to both a "Staff" group entity, 
which specifies access privileges for general staff, and a "Manager" entity which specifies access privileges 
S for managers. 

Similarly, a number of application nodes 81, 82, 83, 84 are shown, each of which includes a 
number of appUcation entities Al, A2, A3, A4. The application nodes are used to defme the access 
pennissions for the application entities, which as described above can correspond to applications software, 
or to data objects on the system, as shown by the object entities 01, 02 which make up the application 
10 entity A4. 

Accordingly, the policy officer uses the structure of the segment, group, principal and apphcation 
nodes to model the business structure. 

As mentioned above, the segment nodes 61, 62, 63, 64 are used to represent different portions of 
the business. Typically, each segment node is an independent unit, which is capable of administmng its 
15 own applications and users, and which. accordingly can fimction autonomously indq)endent of the other 
segment nodes. Accordingly, the administration units typically correspond to different departments, or the 
Uke, within the business. It is also possible that some or all of the administration unit within the hierarchy 
are not within die organization but those of the external organizations e.g. supphers, customers and other 
business partners. 

20 In this case, the segment nodes 65, 66, 67, 68, which are child segment nodes of tiie segment nodes 

61, 64 typically form separate divisions within the departments, which are therefore not necessarily present 
in all cases. This is shown by the segment nodes, 62, 63, which do not include any child segments. 
However, if the segment nodes 61, 64 correspond to larger portions of the business, such as a subsidiary 
business, then the child segment nodes 65, 66, 67, 68 may represent departments within that subsidiary. 

25 The principal nodes are then defined to correspond with individuals within the con^any or in 

external entities. In this case, each individual is represented by a respective principal entity, with each 
principal entity being associated with a respective principal node. 

Similarly, object entities, which represent different objects, and application entities which 
represent different ^pUcations, are associated with respective application nodes. 

30 Once the structure of the business has been determined in terms of the segment, principal, group 

and application nodes, th^ a model of the relationships between these nodes can be constructed using the 
policy server 20. In particular, the policy server 20 provides a graphical user inter&ce (GUI), an example 
of v/hich is shown in Figure 5, to aid this process. 

The GUI shown in Figure 5 is associated with the policy database 36 by the policy server 20 so 

35 that as the structure of die business is defijied using the GUI, the policy server 20 can create entries in the 
policy database so that the hierarchy structure is automatically reflected by the schema of the policy 
database 36. 

In order to implement this, the policy database 36 includes a number of predefined tables, 
including a segment table, a principal table, a group table and an application table. Accordingly, a 
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respective table is provided for each type of node witbin the hierarchy model, allowing each of the tables to 
be used to define respective ones of the nodes that constitute the business hierarchy. 

Thus, for example, each segment node is defined as a respective entry within the segment table. 
Accordingly, in object orientated terms, the segment table can be considered as representing a segment 
5 concept with each segment node being a respective instance of the segment concept 

The tables include pre-defined policy fields that are used to allow the policy of the business to be 
defined This is achieved by providing data (usually in the form of a parameter or numerical value) to set 
the field so that it represents a particular policy. 

The fields are typically dejfined as colmnns within the tables, with each node being provided on a 
10 separate row. Thus, for example, the segment table may include such fields as "password expiry duration", 
"password length", "password warning'*, "password age", and the like. An example of this structure is 
shown in Table 1 below. 



Table 1 



Segment 


Password Expiry 
Duration 


Password Length 


Password 
Warning 


Password Age 























15 

Accordingly, by entering data into the fields, this allows certain characteristics of us^ passwords 
to be defined at the segment level, as will be explained in more detail below. The database tables typically 
include de&ult fields that allow a poUcy officer to define a security policy by sinq)ly entering appropriate 
data. However, the option is also available to allow the policy of&cer to define further fields, as required. 
20 Data is entered into the tables using the GUI mentioned above. Accordingly, the policy of&cer is 

i 

therefore able to define the segment nodes, 61, 62, 63, 64, which correspond to segments wifliin the 

business by simply entering data representative of the respective segment 

An example of this is shown in Figure 5. This example is based on a fictional company XYZ, 

which includes offices in the USA and Asia. 
25 As shown in Figure 5, the GUI includes a structure view 100, which shows the structure of the 

hierarchy which has so far been defined, and an editor screen 101 which is used to define the nodes and 

entities contained within the structure, as well as to edit policies for the defined structOre nodes and ^tities. 
Accordingly as shown in Figure 5 the poUcy officer has defined a root segment node 110, ^^ch 

represents &e company XYZ. 
30 The root segment node has two child segment nodes which have been defined, namely a USA 

office 111 and an Asia region 1 12, the latter of which has a fiirther child segment node, namely a corporate 

segment node 1 14, as showiL 

Each of the root segment node 1 10, the USA segment node 1 1 1, the Asia region segment node 112 

and the corporate segment node 114 include respective principal nodes 120, 122, 123, 125 which are used 
35 to define the security policy for respective individuals within these respective segments. 
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In addition to tiiis, Ifae root segment node 1 10» die Asia region segment node 1 12 and the corporate 
segment node 114 all include req)ective g;roup nodes 121, 124, 126, which allow policy to be set for groups 
of individuals. 

Finally, the application node 113 includes a banking applications entity 127, an SSL c^ficate 
5 applications entity 128, an SSL normal applications entity 129, and a trading applications entity 130. 

As mentioned above, as each node and each entity within the hierarchy is defined using the policy 
server, data is written into an ^propriate table within the policy database. 

Thus, as ttie USA of&ce is defined as a segment node, an appropriate entty will be made in the 
segment table. The appearance of the segment table when all the segment nodes have been defined will be 
10 as shown in Table 2. . 



Table 2 



Segment 


Password Expiry 
Duration 


Password Length 


Password 
Warning 


Password Age 


XYZ Company 










USA OJBBce 










Asia Region 










Corporate 




• 







The policy server 20 then uses this information to generate the stmcture view 100, as shown in 
15 Figure 5. 

As shown in the table 2 above, the segment table defines all the policy fields that are associated 
with die segment nodes. As would be appreciated by a person skilled in the art, these fields are predefined 
by the programs, althougjh they can be adjusted by the policy officer if required 

As the system administrator defimes the USA ofiBce segment node 111, the user will also define 
20 that this is related to XYZ company segment node 1 10, by a parent-child relationship. Accordingly, a link 
is defined between the USA Office entry and the corresponding XYZ Conipany in the segment table. 

This is achieved by having a unique segment ID for each segment in the table, and having a parent 
ID column in the table, indicating the segment ID of any parent segments, as shown in Table 3, which 
shows a restricted portion of the segment table. 

25 



Table 3 



Segment 


Segment ID 


Parent ID 


Password E^qpiry 
Duration 


Password Length 


XYZ Company 


110 








USA Office 


111 


110 






Asia Region 


112 


110 






Corporate 


114 


112 







Thus, for example, ttie USA office segment node includes the segment ID of die XYZ segment 
node in the Parent ID column, thus indicating the XYZ segment node is die parent of die USA OfiBce 
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segment node. Similarly, the XYZ segment node does not include a segment E) in the parent ID column, 
indicating ^t it is the root segment node. 

This process is then repeated for each of the nodes of the business hierarchy, so that all the nodes 
of the hierarchy are entered in the poUcy database in an appropriate one of the tables. 
5 Thus, as would be appreciated by a person skilled in the art, the policy database 35 will include a 

segment table, a principal table, a group table and an application table. As the hierarchy model is defined, 
this is reflected by links between entries in the tables and hence is reflected by the database schema. 

Jn order to define this structure, the user would utilize die edit screen 101. In its default state the 
editor screen includes a structure window 140, and policy window 141, and. a registry window 142. hi 
10 addition to this, an add buttonI43, an edit button 144, a delete button 145, a save button 146, and a cancel 
button 147 are provided. 

In use, if the user wants to add an additional node into the structure, die user need sinq)ly chck on 
the add button 143. The user will then be pron^ted to enter the type of node vMch is to be added within 

* 

the structure. 

15 Once the type of node has been determined, the user will be prompted for additional information, 

which is used to uniquely define the node, and this includes the requirements for a name, which must be 
entered into a name field 148 and a brief description of the node which must be entered into a description 
field 149. 

Once this has been done, the user can access the policy window 141 to define the policies for the 
20 respective node. As described above, a number of default policies aie pre-defined within the policy 
database tables, and these are displayed as shown. 

A poUcy propagation control 150 is provided which allows &e user to select whether the security 
policy of the effective node is inherited firom a parent node 151a or whether the policy is a new policy 
which overrides the policy of the parent as shown at 1 5 lb. In this case, if the policy is inherited, it will be 
25 identical to the policy of the parent node. In the present exan^le, the XYZ Con^any root segment node is 
the parent node of the USA Office segment and accordingly, if the inherit box 151a is checked, the policy 
implemented by the USA office segment node will be identical to that implemented by the XYZ Company 
root segment node. 

In this case, the data entered into the policy fields of the USA segment node, will be obtained 
30 directly firom the respective XYZ company entry in the segment table of the policy database. 

The policy server also includes a turn on maker checker field 151, which is used to activate a 
maker checker procedure which will be explained below, a password lock out field 161, which is used to 
lock out a user if diey enter an incorrect password a predetermined niunber of times, and a password 
restriction field 152. 

35 The password restriction field 152 allows the system administrator to define restrictions on the 

password, such as a password expiry duration 153, a character requirement for the password 154, a warning 
towards password expiry 155, a password age 156, a special character field 157, and a remember password 
section 158. In addition to this, an access time restriction 159, and an access location restriction location 
160 are also defined. 
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Data reflecting the security policy defined by selecting appropriate entries for the fields is dien 
entered into the respective portion of the respective tables in the policy database. 

Thus, in the example of the segment table given above, the table would be modified as shown in 
Table 4 (please note that for clarity purposes only columns corresponding to some of the fields 150-160 
5 have been shown, although in practical implementations a column corresponding to each field would be 
provided). 



Table 4 



Segment 


Password Expiry 
Duration 


Password Length 


Password 
Warning 


Password Age 


XYZ Company 


30 days 


>0 


3 days 


1 day 


USA OfBce 


30 days 


>0 


3 days 


1 day 


Asia Region 










Corporate 






« 





10 Similarly, policy fields are also defined for the remaining principal, group and application nodes. 

In genera] these fields will be similar to those used for the segment nodes. 

Once the node have been defined, similar provisions are made for defining the principal, group, 
application and object entities. In this case, again policy settings are defined using the policy editor GUI 

In the case of the principals, an example of the edit screen 101 is shown in Figure 6. In this case, 
15 the edit screen 101 again includes a principal ID 170 identifying the respective principal, together with a 
name field 171 which includes the name of the principal and a distinguished name 172 which is one of the 
attributes of this user's X509 digital certificate. 

The edit screen also includes an information window 173, which is used to provide basic 
information about the principal, such as their location in the business, or the like. 
20 An accounts screen 174 is provided which sets out details of the principals user account, such as 

the amount of time the user has spent logged on, or the like. 

A privilege screen 175 setting out any access privileges assigned to the user. This allows the 
security manager to define access to applications or information managed by segment nodes other than the 
users own. Thus, in this example, the user "Bob" may form part of tfie banking back-end applications 
25 entity, but may require access to jq)plications or mformation which forms part of the home banking 
applications entity. Accordingly, the user "Bob" is given access privileges under the home banking 
appUcations entity. 

In use, this is achieved by setting an access privilege for the principal entity "Bob" for the home 
banking and banking backend applications entities defined in the applications table within the policy 
30 database, as shown by the ticks 178, 179. 

A memberships screen 176 is used to define which groups the user belongs to. 

A pohcy screen 177 (not shown in detail) is used to define user specific policy, and will therefore 
set out the security settings which apply to the respective user. Again by default, an inherit option is 
available to allow the user to sinqply inherit policy settings bom other entities or nodes. Alternatively, the 
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settings can be defined on an individual basis. 

Once the policy settings have been defined for the entities, the data is written into an appropriate 
one of the database tables. Thus, for example, once the policy settings have been defined for a principal 
entity, a respective entry is made in the principal table, with the respective entity being entered in a 
5 respective row of the table. 

A similar process is followed for group entities, allowing the access policies to be defined for a 
group of principal entities which are associated with the respective group entity. Thus, in the example 
above, if the principal entity ^'Bob" were part of a "Manager" group entity, then access privileges for the 
group entity **Manager" could be set to allow access to the home banking and banking backend application 
10 entities, in a manner similar to that described above with respect to the **Bob" principal entity, thereby 
allowing "Bob" the required access rights. 

Similarly, the security poUcy for application and object entities is controlled by an application 
management screen as shown for example in Figure 7. 

In this example, the structure view 100 shows that the banking applications entity 127 contains a 
1 5 number of object entities 190, such as a cusaccount object entity 191 which is currently selected. 

The applications management screen includes an editor screen 101 which in turn includes a name 
field 180, a descr^tion field 181 and a type field 182, which are together used to identify the respective 
application and/or object entity which is currently selected Thus, as shown the name field 180 include the 
name "cusaccounf ' of the customer account object entity. ' 
20 Method, role, and pennission screens 183, 184, and 185 are also provided. The method screen is 

used to provide details of die method by which is application is accessed, vAereas the role screen 184 is 
used to define the role of the application. 

Roles represent the users of ^plication and their access permissions &om application manager's 
perspective, that is, who is going to use the object of this application, what access rights they have to the 
25 object, and under what conditions. Roles are application-specific, e.g. Teller, Supervisor, Customer. Note 
that die Customer role of application A may be different firom the Customer role of application B. 

Finally the permission screen 185 sets the parameters required for a user to gain access to the 
application and/or object Thus, for example, die permission screen 185 indicates access privileges 
required by a user to access the respective application, as well as any other additional criteria. 
30 An example of the parameters that would be set for the cusaccount object are diat in order to 

access object "cusaccount" using method "transfer", the user must have "customer_c2" role, must log on 
using "certificate", fix)m "LAN", widiin timezone "0900-1600", the cuireny must be "SGD" and die amount 
must be less dian "1000" 

As will be appreciated by persons skilled in the art the information required for the application 
35 management may be entered manually by hand, or through other methods e.g. uploaded, or alternately may 
be obtained by inheritance of information entered elsewhere widiin the GUI system. As a fiirther 
alternative, software can be adapted to automatically add selected information, such as the name and 
description within die respective fields, as the software is installed on the network. 

Accordingly, a policy officer, when presented widi the GUI, can utilize die GUI to define die 
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policy for the business on a number of diflferent levels. To summarize, this is achieved by jSrst determining 
a hierarchy model which models the actual structure of the business. The hierarchy model is then imposed 
on the database schema by defining the hierarchy model using the policy server and the associated GUI, 
with links between various nodes in the defined hierarchy model being represented by Unks between entries 
S within the database tables. 

Once this has been completed, it is then possible for the policy officer to set the security policy, 
firstly for the root segment node, and then for each subsequent node and entity in the hierarchical model. 

Topically by defiuilt, the policy applied to a higher level is automatically inherited by lower levels 
within the database, using for exan:5)le, the inherit option 150a which forms part of the propagate policy 
10 control 150. However, it is possible at any stage to override this inheritance to provide alternative security 
policy features. 

Thus for example it may be that the password requirement in the USA Office is far more restricted 
than for the Asia Region Offices. Accordingly, for these segment nodes which inherit policy fiom the root 
segment node, the policy ofBcer need merely specify new policy settings for the segment node whose 
15 policy differs fix)m that of the root segment node segment. However, the system can configured to prevent 
policy settings of lower segments fiom being weaker than those of the root segment. 

As the policy settings are entered in the respective fields in the policy window, data representative 
of the entry is written into the database, as described above. 

In the case of the principals, the data representative of the policy settings can be stored either in the 
20 policy database, as is ttie case for the policy settings of the segment nodes, or in the user database 35. In 
this case, the user database will include an entry for each principal entity, with the entry providing data 
representative of the respective user name, and password. In fliis case, the principal table in the policy 
database 36 will specify the sectirity settings for the princq)al node, with an association being defined 
between the principal entity and the principal node. This association allows the policy of the principal 
25 entity to be defined by the settings selected for the respective principal node. 

In use, once the security policy has been defined, the security policy is then inqjlemented by the 
access server 23. In order to achieve this, when a user of one of the end stations 2 wishes to access material 
. via the network 1, the user will be requested to enter their name and password or other credentials, either by 
the WSA (web security agent) which forms part of the web server 4, or an ASA (application security agent) 
30 which forms part of the applications server 6. 

The access server 23 will then use the authentication daemon 24 to access the user database 35, via 
the registry API 34, to ensure the password and user name are valid. Assuming this to be the case, the 
access server 23 will cause the WSA or ASA to aUow the user to have access to the network in accordance 
with the access privileges defined for that user. 
35 Once this has been achieved, all subsequent operations that require security clearance must also be 

checked. As described above, this is achieved by having the access server 23 assign a session ID to each 
user whom is logged on to the network. Whenever an action is to be taken, the access server 23 will cause 
the authorization daemon 25 to Access the policy database 36, via the registry API 34, to deteraiine if tiie 
particular action is allowable. This check is perfomed by checking the policy settings for the respective 



wo 2002/067173 



PCT/SG2002/000027 



-23- 



10 



15 



20 



25 



30 



user, using the session ID to identify the user, and aUowing the access server 23 to detemine if the action 
should be allowed. 

If the action is allowed, then an indication of this is transferred to either the WSA or ASA as 
appropriate, otherwise, an inhibit response is transferred causing the WSA or ASA to prevent the user 
taking the requested action. 

The above discussion has focussed on the setting of security policy by a policy officer for 
principals, groups and applications of a business. The subsequent sections will focus on the administration 
aspect of ttie security system. In general, security administration, reviewing and enforcing the security 
policy settings for the entire business will be best achieved by dividing the responsibility amongst a 
nmnberof system operatives. 

Accordingly, it is normal to define a number of administration functions including policy officers, 
security auditors and security administrators. 

The pohcy ofiBcers are in charge of defining the security poUcy for the entire business as a whole, 
using the present invention. The security auditors are in charge of controlling the generation of the audit 
files. 

Finally, the security administrators are in charge of administering the security policy, apphcation 
access permissions, user credentials, and privileges, at this is typically achieved by providing at least one 
security administrator for each segment, with the security administrator being responsible for security 
within the respective segment iiode and any associated child nodes. 

In general, with the security administrators in charge of security wifliin their own respective 
segment, the security administrators are provided with limited powers to alter policy, which will differ for 
each administrator of each segment Accordingly, the administrators are assigned different rights at 
different segments, the rights assigned being only those rights which are required for their job. Thus, m the 
above example, a first security administrator may be associated with and have certain rights for the USA 
office segment node, >^ereas a second different security officer may be placed in charge of the Asia region 
segment node. In this case, the first security officer will typically have no rights over the Asia region 
segment node. 

Examples of administration rigihts implemented are as follows: 



PolicvfPQL^ : 

AuditfAUD^ : 

TraversefTRA'^ : 

SegmentVie-wfSVWl : 

PrincipalViewfPVW^ ! 

ObiectViewrOVW^ : 

SegmentControlfSChn : 



Right to set and change security policy 

Right to review audit logs 

Right to traverse the hierarchy 

Right to view (the details of) segment 

Right to view (the details of) user 

Right to view (the details of) object 

Right to create/delete/modify administrator 

and segment structure (User, Group, 

apphcation nodes and sub-segment nodes) 

Right to create/delete/modify user 

Right to create/delete/modify object 



PrincipalControinPCNn : 
ObiectControlfOCKn : 
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PrincipalRn ablefPETsn : Right to enable/disable user 

PrincipalForcefPFR^ : Right to force user change password 

PrincipalResetflPRS'^ : Right to reset user password 

Adm^riififTft to^Enable^AE^f> : Right to enable/disable administrator 

S Adminififr atorForcefAFRV Right to force administrator to alter password 

AdminiRtr atorResetf ARSY . Rig^t to reset administrator password 

As mentioned above, each security administrator can usually only alter the policy settings of their 
own respective segment and any nodes such as group nodes, principal nodes or application nodes, or sub- 
1 0 segment nodes, which fall within the respective segment. 

However, the rights given to the security administrators can be carefully controlled. Thus for 
example, the security administrators woxild typically not be given the POL administration rights which 
allows the security adbninistrator to change the security policy within the segment. Instead they are 
typically only given rights such as PCN, OCN, PEN, or ottier similar rights, which allow them to control 
15 the access privileges of independent entities within the nodes. 

Furthermore, the rights assigned to the security administrators are set for each segment separately. 
As a result, a security administrator may have far greater administration rights in one segment than another. 

It will be appreciated from this that the rights for the security administrators must be set at the 
segment node level, using the policy editor GUI, to allow different rights to be provided for different 
20 security administrators in each segment. 

As a result of this system, the overall security policy of the business can be maintained by the 
policy officer, whilst allowing the security applied to an individual to be changed by a respective security 
administrator, as necessary. 

The pohcy officer will generally have the right to overtum any action taken by any security 
25 administrator. In particular, the policy officer is provided with an option which allows the synchronisation 
of the security policy for all segment nodes within the business. Accordingly, this can be used to ensure 
that a uniform security policy is in place across the entire business. 

By allowing the administration rights for each security administrator to be tightly controlled, this 
prevents administrators being able either accidentally, or intentionally, to interfere with flie security policy 
30 of the business, or access privileges of individuals in other segments. 

In order to provide a further control, such powerful administration rights are subject to a security 
feature called maker-checker control. 

This system operates by assigning at least two security administrators to a respective segment In 
this case, any one of the security administrators with a POL Maker right has the right to propose changes to 
35 security policy, whereas a second security administrator with a POL Checker right only has the right to 
confirm changes proposed by the first security administrator. Accordingly, a change in policy can only be 
achieved if this is first proposed by the first security administrator and then confirmed by the second 
security administrator, thereby preventing one single individual having the right to modify security policy. 

The present invention also provides a system for logging actions taken by users of the system. 
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This is achieved using the audit daemon 29, which is located within the security system 3, La use, the audit 
daemon 29 operates to record each action that is taken within an audit log table in the log store 38. 

Tliis operation can be achieved by having the server con^)onents, such as the authentication and 
au&orization daemons 24, 25 call the audit daemon whenever an action is in progress. Accordingly, each 
5 time an authorization for an action is provided by the authorization daemon, this &ct is recorded by the 
audit daemon 29 in a current log table. The audit daemon 29 will store an indication of the nature of the 
request (i.e. what action was requested) and whether the action was authorized (i.e. whether a proceed or 
inhibit response was generated by the access server 23). 

Information regarding each action taken is written into the audit log table as a new record. This 
10 record will be digitally signed before it is written into the audit log table, with an indication of the time and 
date at which the action occurred. This provides integrity protection of the audit log, and allows the audit 
daemon 29 to access the audit log table at a later date and determine at what time a particular user 
performed a particular action. 

The audit log table may periodically be stored or archived, with a further digital signature being 
15 provided during the process to ensure security of die records. This signature will include encoded 
information regarding the number of actions recorded and when the log was created. Typically this will 
occur either after a predetermined amount of time, such as one hour, or after a predetmnined number of 
actions have been recorded and the log file is full. 

In addition to this, the log store 38 could be located on a dedicated secure server, thereby further 
20 preventing the logs being tampered with. 

Thus, the present invention operates to enforce enterprise security policies effectively by: 

a) Defining security poUcies, user privileges and object permissions based on a segmented hierarchy 
model of users, groups and applications. A segment is an administration unit, which may consist of 

25 Users (Principals), Objects (Applications), and sub-segments. The segmented hierarchy is closely 

mirrors a company's existing organization structure. Roughly speaking, a segment corresponds to 
an organization's department or unit that manage its own applications and users. 

b) The security policy can be defined at root segment level or sub-segment level. A sub-segment can 
inherit the security policy fix>m its parent segment Sub-segments may override its parent's policy. 

30 On the other hand, parent segments can synchronize its security policy within all subordinated 

segments. The change of security policy at a segment can immediately be enforced to whole 
segments and its subordinated segments. 

c) Users and objects are defined within the segmented hierarchy. They are automatically subjected to 
the security policy specified at the segment where fliey are defined. 

35 d) The security policy is defined by Security Policy OfScers, used and enforced by Security 

Administrators, reviewed by Security Auditors. 

To provide granular access control of security administration with built-in support for the best 
industrial security practices & principals like Segregation of Duty and Least Privilege. 

a) Security administrators are segregated firora system administrators througji the use of different 
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administration interfaces. In particular, security administrators use the policy editor, whilst the 
system administrators use the service server. 

b) Security Administrators are defined at segment level and can be assigned to very granular 
administration rights, as set out above. 

* 

c) Security Policy Officer, Security Auditor and Security Administrator functions are differentiated 
from each other by rights. Administrators are assigned to different rights at different segments. 
They can be only assigned to those rights, which are required for their job. Access Matrix can 
ensure that Policy and Audit v^iU not assigned to those security administrators who have other 
administration rights. 

d) The scope of the assigned administration rights is limited to the segment where this administrator 
is defined and its subordinated segments. 

e) Administrators without the Policy right cannot modify security policies. 

f) Administrator with Delegation Option can delegate part or all of his/her rights to other 
administrators. The grantor can later on revoke the rights he/she granted to a grantee, which cause 
root segment to revoke the rights that the grantor has granted, automatically and recursively. 

g) Changes to powerful administration rights i.e. fliose with control rights can be subjected to Maker- 
Checker control In a segment where the Maker-Checker control is on, all modification-related 
administrator's rights will be marked as either Maker or Checker. Only the Maker can submit 
requests, which must be approved by respective Checker before the root segment performs the 
action. Maker-Checker Control policy can be configurable to turn on or off at segment level. 

h) Users are only assigned to the roles of those applications and objects, to which they are required to 
access. The present invention defines Mutually Exclusive Role Group (MERG) to ensure that a 
user at any time can assume at most one role within a MERG. 

i) Dynamic Segregation of Duty within business applications is supported by parameter-conditions. 
For example, assume that withdraw cash needs to be duly controlled by two roles: Submitter and 
Approver and two methods: 

WithdrawjCashJSubmit and WithdrawjCash_Approve. The following 
condition will ensure that the Approver is not the Submitter of same 
transaction: 
<Approver, 

Withdraw_Cash_Approve, 
(Submitter != ROLE^HOLDER) > 

(Here the Submitter is input parameter while ROLE_HOLDER is 
system-defined variable that is set to the current holder of the role i.e. 
Approver. Note that same person may be assigned to these two roles 
because of small team sizes.) 

Accordingly, the present invention seeks to provide a security administration framework for large- 
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size, mission-critical and security-sensitive environment which provides: 

1) Built-in support for enterprise-wide security policy enforcement 

2) Built-in si;^ort for best industrial security practices & principals like Segregation of 
Duty and Least Privilege 

3) Scalable to support many different users and applications 

4) Flexible enou^ to define and control secuhty-ielated business rules wiftin one single 
organization or across multiple organizations. 

It will be appreciated by persons skilled in the ait that numerous variations and modifications will 
become a{^arent All such variations and modifications which become s^jpaxent to persons skilled in the 
art, should be considered to M wi^iin the spirit and scope of die invention as broadly hereinbefore 
described. 
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THE CLAIMS: 

1) A hi^archy model for modelling the security policy of a business, the hierarchy model including: 

a) A number of segment nodes, each segment node being used to define the security policy which 
apphes to a respective segment of the business, each segment being associated with a number of 

5 respective individuals and/or applications, each segment node including at least one of the 

following: 

i) A principal node, the principal nodes being used to define the security poUcy which implies to 
respective individuals within the business, each principal node including one or more principal 
entities, and each principal entity corresponding to a respective individual; 

10 ii) An application node, the application nodes being used to define the security policy which 

apphes to respective appUcations or objects within the business, each appUcation node 
including one or more application or object entities, and each appUcation or object entity 
cotresponding to a respective appUcation or object; 
iii) A group node, the group nodes being used to define the security poUcy which applies to 

IS respective groins of principals within the business, each group node including one or more 

group entities, and each group entity corresponding to a group of respective individuals; 

b) A number of connections, the connections defining associations between the nodes to reflect the 
structure of the business. 

2) A hierarchy model according to claim 1, wh^in each segment node may include one or more child 
20 segment nodes, each child segment node definmg the security poUcy for a logical unit within the 

respective parent segment. 

3) A hierarchy model according to claim 2, wherein the hierarchy model fiuther includes at least one root 
segment node, the root segment node being a segment node with no parent nodes. 

4) A hierarchy model according to any of the preceding claims, wherein &e model further includes 
25 appUcation coUection entities, each appUcation collection entity representing a collection of appUcation 

ratities. 

5) A hierarchy model according to any of the preceding claims, wherein the model is implemented within 
a database, the database including a nvunber of tables, each table representing a respective type of node 
withia the model 

30 6) A hierarchy model according to claim 5, the database including a segment table, and wherein each 
segment node is represented by a respective entry within the segment table. 

7) A hierarchy model according to claim 5 or claim 6, the database including a principal table, and 
wherein each principal entity is represented by a respective entry within the principal table. 

8) A hierarchy model according to any of claims S to 7, the database including a group table, and wherein 
35 each group entity is represented by a respective entry within the group table. 

9) A hierarchy model according to any of claims 4 to 7, the database including a appUcation table, each 
appUcation entity, object entity and appUcation coUection entity being represented by a respective entry 
in the application table. 
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10) A hierarchy model according to any of claims 5 to 9, wherein the number of connections are 
represented by links between entries in the tables. 

11) A hierarchy model according to any of the preceding claims, wherein each node within the model has 
an associated number of security settings, die security policy being defined by selecting appropriate 

5 ones of the security settings. 

12) A hierarchy model according to claim 1 1, when dependent on any of claims 5 to 10, wherein each 
entry is defined in a respective row of the respective table, with each security setting being defined 
within a respective colunm. 

13) A hierarchy model according to claim 11 or claim 12, wherein each type of node has respective 
10 security settings. 

14) A hierarchy model according to any of the preceding claims, wherein each segment corresponiis to a 
group of related business attributes capable of managing the associated appUcations and individuals. 

15) A hierarchy model for modelling the security policy of a business substantially as hereinbefore 
described. 

15 16) A method of generating a hierarchy model for modelling die security policy of a business, the method 
including: 

a) Defining the business as a number of segments, each segment being a respective unit within the 
business; 

b) Determining the individuals, groups of individuals and/or applications associated with each imit; 
20 c) Defining a number of segment nodes, each segment node being used to define tiiie security policy 

which applies to a respective segment of the business; 
d) Defining at least one principal, group and/or application node, each princ^al, group and/or 
^plication node being used to define the security policy which applies to respective individuals, 
groups of individuals and/or applications; and, 
25 e) Defining a number of cormections between the defined nodes in accordance with the relationships 

between the segments, individuals and/or applications to reflect the structure of the business. 

17) A method according to claim 16, the method fiirther involving defining: 

a) principal entities, each principal entity corresponding to a respective individual; 

b) one or more application or object entities, and each application or object entity corresponding to a 
30 respective application or object; and, 

c) one or more group entities, and each group entity corresponding to a group of respective 
individuals; 

18) A method according to claim 16 or claim 17, wherein the method further includes: 
a) Generating a database, the database being formed from a number of tables; and, 

35 b) Associating each table with a respective type of node. 

19) A method according to claim 18, wherein the method further includes defining: 

a) Each segment node as a respective entry within the segment table; 

b) Each principal entity as a respective entry within the principal table; 

c) Each group entity as a respective entry within the group table; and. 
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d) Each application entity, object entity and/or application collection entity as a respective entry in 
the q)plication table. 

20) A method according to claim 19^ wherein tiie method furdier involves defining the number of 
connections by defining links between entries in the tables. 
5 21) A method of generating a hierarchy model substantially as hereinbefore described. 

22) A method according to any of claims 16 to 21, wherein the hierarchy model is a model according to 
any of claims 1 to IS. 

23) ' A computer program product including computer executable program code for generating a hierarchy 
model in accordance with the method of any of claims 16 to 22. 

10 24) A conq)uter program product accprding to claim 23, the computer executable code being stored on a 
con^uter readable mediuiTL 

25) A computer prpgram product including computer executable program code for generating a hierarchy 
model substantially as hereinbefore described. 

26) A system for generating a hierarchy model for modelling the security policy of a business, the 
1 5 hierarchy model including: 

a) An input, adapted to receive inputs: 

i) Defining the business as a number of segments, each segment being a respective imit within 

« 

the bxosiness; 

ii) Identifying the individuals and/or applications associated with each unit; 

20 iii) Defining a number of segment nodes, each segment node being used to define the security 

policy which applies to a respective segment of the business; 
iv) Defining at least one principal, group and/or application node, each principal, group and/or 

application node being used to define the security policy which appHes to respective 

individuals, groups of individuals and/or applications; and, 
25 v) Defining a number of connections between die defined nodes in accordance with die 

relationships between the segments, individuals and/or applications to reflect the structure of 

the business. 

b) A store; and, 

c) A processor adapted to: * 
30 i) Generate a number of tables in the store; 

ii) Associate each table widi a respective node in the hierarchy model; and, 

iii) Define a number of links between the tables, each link representing a connection between 
respective nodes Mdthin the tables. 

27) A system according to claim 26, wherein input is adapted to allow the user to define: 
35 a) principal entities, each principal entity corresponding to a respective individual; 

b) one or more application or object entities, and each appUcation or object entity corresponding to a 
respective application or object; and, 

c) one or more group entities, and each group entity corresponding to a group of respective 
individuals; 
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28) A system according to claim 27, v4ierein the processor is further adapted to define: 

i) Each segment node as a respective entry within the segment table; 

ii) Each principal entity as a respective entry within the principal table; 

iii) Each group entity as a respective entry within the group table; and, 

S iv) Each application entity, object entity and/or application collection entity as a respective entry 

in the application table. 

29) A system according to claim 28, herein the processor is fiir&er adapted to delBne the number of 
connections by defining links between entries in ttie tables. 

30) A system according to any of claims 26 to 29, the system further including a display, and wherein the 
10 processor is adapted to display icons to the user of the system, the icons representing segment nodes, 

application nodes, group nodes and principal nodes, the system being adapted to allow the user to 
define: 

i) Define the business as a number of segments, by arranging segment icons on the display; 

ii) Identify the individuals and/or applications associated with each segment by airanging 
IS application^ group and principal node icons on the display; and, 

iii) Define relative interconnections between the defined nodes by allowing the user to link the 
respective icons. 

31) A system for generating a hierarchy model substantially as hereinbefore described with reference to the 
accompanying dravtnngs. 

20 32) A system according to any of claims 26 to 31, the system generating a hierarchy model according to 
any of claims 1 to 15. 

33) A method of defining a security policy for a business, the method including: 

a) Defining the business in tenns of a hierarchy model, the hierarchy model includiug: 

i) A number of segment nodes, each segment node being used to define the security policy which 
25 applies to a respective segment of the business; 

iO At least one principal, group and/or application node, each principal, group and/or application 

node being used to define the security policy which applies to respective individuals, groups of 

individuals and/or applications; and, 

iii) A number of connections between the defined nodes, the comiections representing the 

» 

30 relationships between the segments, individuals and/or applications to reflect the structure of 

file business. 

b) Specifying the security policy for at least some of the nodes in the hierarchy model; and, 

c) Propagating the specified security policy to other nodes in the hierarchy model. 

34) A method according to claim 33, wherein the hierarchy model is a model according to any of claims I 
35 to 15. 

35) A method according to claim 33 or claim 34, wherein the method of defining the business in terms of a 
hierarchy model includes generating a hierarchy model in accordance with the method of any of claims 
16 to 22. 
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36) A method according to claim 35, when dependent on claim 20, wherein the method of defining the 
security settings for a node includes: 

a) Generating security data defining security settings for the respective node; and, 

b) Inputting the security data as part of the respective entry within the respective table within the 
5 database. 

37) A method according to claim 36, wherein the method further involves propagating the defined security 
settings to other nodes in the hierarchy model by propagating the security data to other linked entries in 
the database. 

38) A method according to claim 30, wherein the security settings applied to a child segment node may 
1 0 override the security settings propagated from the respective parent segment node. 

39) A method of defining a security policy for a business substantially as hereinbefore described 

40) A computer program product including computer executable code for defining a security poUcy for a 
business in accordance with the method of any of claims 33 to 40. 

41) A computer program product according to claim 40 stored on a computer readable medium. 

IS 42) A computer program product including computer executable code for defining a security policy for a 
business substantially as hereinbefore described 

43) A system for defining a security policy for a business or extended organisations, the system including: 

a) A system for defining the business in terms of a hierarchy model, the hierarchy model including: 

i) A number of segment nodes, each segment node being used to define the security policy which 
20 applies to a respective segment of the business or ext^ded organisations; 

ii) At least one principal, group and/or application node, each principal, group and/or s^lication 
node being used to define the security policy which applies to respective individuals, groups of 
individuals and/or applications; and, 

iii) A number of coimections between the defined nodes, the connections representing the 
25 relationships between the segments, individuals and/or applications to reflect the structure of 

file business. 

b) An input, adapted to receive inputs specifying the security policy for at least one of the nodes in 
the hierarchy model; and, 

c) A store for storing the specified security poUcy; and, 

30 ' d) A processor adapted to propagate the specified security policy to other nodes in the hierarchy 

model. 

44) A system according to claim 43, wherein the system for defining the business in terms of a hierarchy 
model, includes a system according to any of claims 26 to 32. 

45) A system according to claim 44, when dependent on at least claim 28, wherein the system is adapted to 
35 receive inputs specifying the security policy for at least one of the nodes in the hierarchy model by 

receiving security data defining security settings for the respective node, the processor being adapted to 
input the security data as part of the respective entiy within the respective table within the database. 
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46) A system according to claim 45, when dependent on claim 29, wherein the metiiod further involves 
propagating the defined security settings to other nodes in the hierarchy model by propagating the 
security data to other linked entries in the database. 

47) A system for defining a security policy for a business substantially as hereinbefore described with 
5 reference to the accompanying drawings. 

48) A method of implementing a security policy for a business, the method including: 

a) Defining a security policy for the business, the security policy being defined in terms of a 
hierarchy model including: 

i) A numb^ of segment nodes, each segment node representing a respective segment of the 
10 business; 

ii) At least one principal, group and/or application node, each principal, group and/or ^phcation 
node representing a respective individual, groiip of individuals and/or applications within the 
business; and, 

■ 

iii) A number of connections, the connections defining the associations between flie nodes, ftiG 
1 5 security poUcy being defined by security settings associated witti each node; 

b) Monitoring action to be taken by a respective segment, individual or appUcation within the 
business; 

c) Determining if the action is permissible in accordance with the defined security settings; and, 

d) Allowing or preventing the action in accordance with the result of the determination. 

20 49) A method according to claim 48, wherein the security policy is defined in accordance witti tiie method 
of any of claims 33 to 39. 

50) A method according to claim 48 or claim 49, wherein the security settings are stored in a database 
associated with the respective segment, principal, group and/or object node, the method of determining 
if the action is permissible including: 

25 a) Accessing the database to determine the security settings for the respective segment, individual 

and/or application; and, 

■ ■ 

b) Comparing the accessed security settings to the action to be taken to determine if the action is 
permitted. 

51) A method according to any of claims 48 to 50, wherein the hierarchy model is a model according to 
30 any of claims 1 to 15. 

52) A method of implementing a security policy for a business substantiaUy as hereinbefore described. 

53) A computer program product including computer executable code for implementing a security policy 
in accordance with the method of any of claims 48 to 52. 

54) A computer program according to claim 53 stored on a computer readable medium. 

35 55) A computer program product including computer executable code for implementing a security policy 
for a business substantially as hereinbefore described. 

56) A system for implementing a security policy for a business, the security policy being defined in temis 
of a hierarchy model, the hierarchy model including: 

57) A system for implementing a security policy for a business, the system including: 
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a) A system for defining a security policy for the business, the security policy being defined in terms 
of a hierarchy model including: 

i) A nimiber of segment nodes, each segment node representing a respective segment of the 
business; 

5 ii) At least one principal, group and/or appUcation node, each principal, group and/or application 

node representing a respective individual, group of individuals and/or appUcations within the 
business; and, 

iii) A number of connections, die connections defining the associations between the nodes, the 
security policy being defined by security settings associated with each node; and, 
10 b) A processor, the processor being adapted to: 

i) Monitor action to be taken by a respective segment, individual or appUcation within the 
business; 

ii) Detennine if the action is pennissible in accordance with the defined security settings; and, 

iii) Allow or prevent the action in accordance with the result of the detennination. 

15 58) A system according to claim 57, wherein the system for defining a security policy for the business is a 
system according to any of claims 43 to 47. 

59) A system according to claim 57 or claim 58, wherein the system is adapted to receive action data 
representing the action to be taken, and wherein die security settings are defined in tenns of security 
data stored in a store, and wherein the processor is adapted to: 

20 • a) Access the store to determine the security data for the respective segment, individual and/or 

applicatioi^ and, 

b) Comparing the accessed security data to the action data to determine if the action is permitted 

60) A system for implementing a security poUcy for a business substantially as hereinbefore described with 
reference to the accompanying drawings. 

25 61) A method of controlling the admiiustration of the security policy of a business, the security poUcy 
being defined using a hierarchy model including. 

a) A number of segment nodes, each segment node having an associated number of security settings, 
the segment node being used to define the security policy which applies to a re^ective segment of 
the business by selecting appropriate ones of the security settings; and, 
30 b) A number of connection, the connections defining associations between the segment nodes to 

reflect the stmcture of the business, the method including: 

i) Assigning an administrator to each segment; 

ii) Defining administration rights that can be assigned to any administrator, the administration 
rights controlling the administration procedures the respective administrator can perform; and, 

35 iii) Assigning appropriate ones of the administration rights to the administrator, if required. 

62) A method according to claim 61, wherein the method of assigning the admimstrator includes defining 
an administrator entity for each segment, the administrator entity representing a respective individual 
within the business. 
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63) A method according to claim 62, wherein the method of controlling the administration rights includes 
assigning appropriate ones of the administration rights to the defined administrator entity. 

64) A method according to claim 63, wherein the administration rights are defined at the system level but 
the scope of the administration rights is limited to the segment where the administrator is defined and 

5 its subordinate segments. 

65) A mefliod of controlling the administration of the seciuity policy of a business substantially as 
hereinbefore described. 

66) A computer program product for controlling the administration of the security poUcy of a business, the 
computer program product including computer executable code for performing the method of any of 

10 claims 61 to 65. 

67) A computer program product according to claim 66 stored on a computer readable medium. 

68) A computer program product for controlling the administration of tiie security poUcy of a business 
substantially as hereinbefore described. 

69) A system for controlling the administration of the security policy of a business, the security policy 
1 5 being defined using a hierarchy model including: 

a) A number of segment nodes, each segment node having an associated number of security settings, 
the segment node being used to define the security poUcy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 

b) A nimiber of coimections, the connections defining associations between die segment nodes to 
20 reflect the structure of the business, the system including: 

i) An input for: 

(1) Receiving an indication of an administrator assigned to each segment; and, 

(2) Defining administration rights; and, 

(3) Assigning appropriate ones of the administration rights to the administrator, if required; 
25 and, 

ii) A processor adapted to control the administration procedures the respective administrator can 
perform in accordance with the defined administration rights. 

70) A system for controlling the administration of the security policy of a business substantially as 
hereinbefore described with reference to the accon^anying drawings. 

30 71) A method of controlling the administration of the security policy of a business, the security policy 
being defined using security settings, the method involving: 

a) Assigning first and second administrators to control alteration of the security settings; 

b) Controlling the first administrator to only allow the first administrator to propose changes to the 
security settings; and, 

35 , c) Controlling the second administrator to only allow the second administrator to accept or reject 

proposed changes to the security settings, thereby allowing the first and second administrators to 
control the security settings. 
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72) A method according to claim 71, i^etein the method of assigning the first and second administrators 
includes defining first and second administrator entities, each administrator entity being associated 
with a respective individual wifliin the business. 

73) A method according to claim 72, wherein the method of controlling the administrators includes: 

5 i) Defining a number of administration rights that can be assigned to any administrator entity, the 

administration rights controlling the administration procedures the respective administrator 
can perform; and, 

ii) Assigning appropriate ones of the administration rights to the respective administrator entity, 
if required. 

10 74) A method according to claim 73, wherein the administration rights are selected ones of the security 
settings and wherein the administration rights are selected to prevent an administrator altering the 
administration rights of their own respective administrator entity. 
75) A method according to any of claims 71 to 74, wherein the hierarchy model includes: 

a) A number of segment nodes, each segment node having an associated number of seciirity settings, 
IS the segment node being used to define the security poUcy which applies to a respective segment of 

the business by selecting appropriate ones pf the security settings; and, 

b) A number of connections, the connections defining associations between the segment nodes to 
reflect the structure of the business, and wherein the method includes assigning respective first aqd 
second administrators to each segment 

20 76) A method for controlling the security policy of a business substantially as hereinbefore described. 

77) A con^)uter program product including con^uter executable code for controlling the administration of 
the security policy of a business in accordance with the method of any of claims 71 to 76. 

78) A computer program product according to claim 77 stored on a computer readable medium. 

79) A system for controlling the administration of the security policy of a business, the security poUcy 
25 being defined using security settings, die system including: 

a) An input for assigning firat and second administrators to control alteration of die security settings; 
and 

b) A processor adapted to: 

i) Control the first administrator to only allow the first administrator to propose changes to the 
30 security settings; and, 

ii) Control die second administrator to only allow the second administrator to accept or reject 
proposed changes to the security settings, thereby allowing the first and second administrators 
to control the security settings. 

80) A system for controlling the administration of the security policy of a business substantially as 
35 hereinbefore described with reference to the accompanying drawings. 

81) A method of controlling the administration of the security policy of a business, the security policy 
being defined using a hierarchy model including: 



■ 
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a) A numbo: of segment nodes, each segment node having an associated number of security settings, 
the segment node being used to define the security policy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 

b) A number of connections, the connections defining associations between the segment nodes to 
5 reflect the structure of the business, the method including: 

i) Assigning an administrator to each segment, the administrator being responsible for the 
security settings of the respective segment; and, 

ii) Allowing a first administrator to delegate responsibility for the security settmgs of a respective 
segment to a second administrator. 

10 82) A method according to claim 81, wherein the method of assigning ttie administrator includes defining 
an administrator entity for each segment, the administrator entity representing a respective individual 
wi'diin &e business. 

83) A method according to claim 82, wherein an administrator is assigned to a segment by specifying the 
respective administrator entity in the security settings for the segment, and wherein the method of 

IS delegating responsibility includes specifying the second administrator in the respective security 
settings. 

84) A method according to any of claims 81 to 83, wherein the method further includes defining a number 
of admimstration rights for each administrator entity, the administration rights defining which security 
settings can be altered by the respective administrator. 

20 85) A method according to claim 84, wherein the method of delegating responsibility includes: 

a) Determining if the administration rights for the first and second administrators allow responsibility 
to be delegated; and, 

b) Selecting some or all of the administration rights for the second administrator to correspond to the 
administration rights for the first administrator, thereby allowing the second administrator to 

25- perform some or all of function of the first 

86) A method of controlling the administration of the security policy of a business substantially as 
hereinbefore described. 

87) A computer program product including computer executable code for controlling the administration of 
the security policy of a business in accordance with the method of any of claims 81 to 86. 

30 88) A con^)uter program product according to claim 87 stored on a computer readable mediunt 

89) A computer program product including computer executable code for controlling the administration of 
the security policy of a business substantially as h^einbefore described. 

90) A system for controlling the administration of the security policy of a business, the security policy 
being defined using a hierarchy model including: 

35 a) A number of segment nodes, each segment node having an associated number of security settings, 

the segment node being used to define the security policy which applies to a respective segment of 
the business by selecting appropriate ones of the security settings; and, 
b) A number of connections, the connections defining associations between the segment nodes to 
reflect the structure of the business, the system including: 
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i) An input for assigning an administrator to each segment, the adnoinistrator being responsible 
for die security settings of the respective segment; and, 

ii) A processor adapted to allow a first administrator to delegate responsibility for the security 
settings of a respective segment to a second administrator. 

S 91) A system for controlling the administration of the security policy of a business substantially as 
hereinbefore described. 

92) A method of monitoring a security system which implements a security server, the method including: 

a) Causing the security server to generate an indication of each action taken on the security system; 

b) Digitally signing die indication of each action; and, 
10 c) Storing the digitally signed indication. 

93) A method according to claim 92, wherein the method includes storing the digitally signed indication in 
a table, each digitally signed indication being stored in a respective portion of the table. 

94) A method according to claim 93, wherein the table is located remotely to the security system on ore or 
more dedicated systems. 

IS 95) A method according to claim 92, wherein the security server is adapted to generate an auAorisation or 
rejection indication in response to a request to perform an action, and wherein the method further 
includes causing the security server to generate an indication of each authorisation or rejection. 

96) A method of monitoring a security system substantially as hereinbefore described 

97) A computer program product including computer executable code for monitoring a security system in 
20 accordance wilh the method of any of claims 92 to 96. 

98) A computer program product including conq}uter executable code for monitoring a the each action 
taken on the security system substantially as h^einbefore described. 

99) A system for monitoring a security system which implements a security server, the system con:q>rising: 
. a) An input for receiving an indication of each action taken on the security systen:!; 

25 b) A processor for digitally signing the indication; and, 

c) A store for storing the digitally signed indication. 

100) A system according to claim 99, wherein the store is located remotely to the security system on 
one or more dedicated systems 

101) A system according to claim 99 or claim 100, wherein the processor is adapted to store the 
30 digitally signed indication in a table, each digitally signed indication being stored in a respective 

portion of the table. 

102) A system according to any of claims 99 to 101, wherein security server forms part of die system, 
and wherein the security server comprises a security processor adapted to generate an authorisation or 
rejection indication in response to a request to perfonn an action. 

35 1 03) A system for monitoring a security system substantially as hereinbefore described. 
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